This invention relates generally to Interactive Connectivity Establishment (ICE) and more particularly to using ICE across restrictive security boundaries such as restrictive Network Address Translator (NAT) boundaries or firewalls.
Endpoints such as Internet Protocol (IP) phones can make multimedia communications such as Voice over IP (VoIP) calls using multimedia session signaling protocols such as Session Initial Protocol (SIP). Devices such as NATs located between two endpoints can prevent the flow of multimedia session signaling protocol messages between the two endpoints. ICE was developed to allow multimedia communications to operate through NATs.
Even though ICE was developed to allow multimedia communications to operate through NATs, ICE is generally used before any multimedia communications whether or not NATs are located between two communicating endpoints. ICE is used because an endpoint is generally unaware of how many, if any, NATs are located between itself and another endpoint.
FIG. 1 shows IP phones A and B utilizing ICE to communicate using multimedia session signaling protocol. For simplification, an example is shown where there are no NATs located between IP phones A and B.
IP phone A first utilizes any method available to determine what IP addresses and port combinations that are used for receiving media streams. In this instance, IP phone A uses Simple Traversal of User Datagram Protocol (UDP) Through NATs (STUN). The STUN communications 101 are used with a STUN server 22 to determine the IP address X and UDP port number for IP phone A (IP=X). IP phone A then makes a local STUN server 23 available on itself and associates a unique identifier 8a with that IP address X. As defined by ICE, the unique identifier 8a is generated by combining random bit values with media level attributes.
Next, IP phone A sends call request 102 including IP address X and the unique identifier 8a to a call controller 1. In this example the IP phone A is making a VoIP communication, and therefore, the call controller 1 is a VoIP call controller. VoIP call controller 1 sends call request 103 including IP address X and unique identifier 8a to VoIP call controller 2 for IP phone B. VoIP call controller 2 sends a call request 104 to IP phone B that includes IP address X and unique identifier 8a 
After receiving call request 104, IP phone B may use any method to determine what IP addresses and port combinations may be used to receive media streams. In this example, IP phone B also uses STUN. STUN request 105a is sent to STUN server 22 to determine the IP address Y and UDP port number for IP address Y (IP=Y) for IP phone B.
Also after the call request 104 is received, and generally in parallel with the STUN request 105a, IP phone B sends a STUN request 106 to the STUN server 23. The purpose of the STUN request 106 is for IP phone B to verify that it can reach IP phone A at IP address X. Included in the STUN request 106 is the unique identifier 8a. 
IP phone A receives STUN request 106 and verifies the unique identifier 8a before sending back a STUN response 107. The STUN response 107 is shown to arrive before the accept message 108 is sent, however depending on network characteristics, the STUN response 107 may instead arrive at a later time as indicated by dashed line 107.
After receiving STUN response 105b back from the STUN server 22, IP phone B makes a local STUN server 24 available on IP address Y and associates a unique identifier 8b with that IP address Y. Also after receiving STUN response 105b, IP phone B sends an accept message 108 to IP phone A. The accept message 108 also includes the IP address Y and the unique identifier 8b. The accept message 108 may be sent before the STUN response 107 is received as indicated by dashed line 107.
After receiving the accept message 108, IP phone A sends a STUN request 109 to STUN server 24 to verify that it can reach IP phone B at IP address Y. Included in the STUN request 106 is the unique identifier 8b. IP phone B receives the STUN request 109 and sends a STUN response 110 after optionally verifying the unique identifier 8b. Media communications 111 begin after IP phones A and B verify that they can communicate with each other as described above.
FIG. 2a shows how ICE operates with a device 11 that restricts the flow of communications to and from IP phone A. In this example, device 11 is a restrictive firewall that restricts the flow of inbound and outbound communications with devices that are not included on an “always permitted” list 12 (hereinafter referred to as list 12). In other examples device 11 is a restrictive NAT 11. The device 11 restricts more communications than a conventional NAT. For example, a conventional NAT does not restrict inbound communications from IP addresses that IP phone A has used to send outbound communications.
ICE begins normally with IP phone A first sending a STUN request 201a to STUN server 22. Firewall 11 forwards the STUN request 201a and associated STUN response 201b because the associated address is on the list 12. IP phone A then makes local STUN server 23 available on IP address X and associates a unique identifier 8a with that IP address X.
Next, IP phone A sends call request 202 to VoIP call controller 1. Firewall 11 forwards the call request 202 because to the associated address for the VoIP call controller 1 that is included on the list 12. VoIP call controller 1 sends a corresponding call request 203 to VoIP call controller 2 for IP phone B. VoIP call controller 2 sends a corresponding call request 204 to IP phone B.
After receiving call request 204, IP phone B sends STUN request 205a. IP phone B also sends a STUN request 206 to the STUN server 23, which is intercepted by firewall 11. Because IP phone B is not on the list 12, the STUN request 206 is dropped and not received by IP phone A.
IP phone B does however receive STUN response 205b back from STUN server 22. Accordingly, IP phone B makes a local STUN server 24 available on IP address Y and associates a unique identifier 8b with that IP address Y. Because firewall 11 intercepts and drops the STUN request 206, ICE cannot be completed and multimedia communications cannot be transferred between IP phones A and B.
FIG. 2b shows the IP phone A located behind asymmetric firewalls 18 and 19. Firewalls 18 and 19 are asymmetric because outbound communications are received at one firewall 18, while inbound communications are received at another firewall 19. This asymmetric routing occurs due to normal asymmetric IP routing in network 15a and network 15b. Firewalls 18 and 19 have the same policy restrictions as conventional NATs in that they only restrict the flow of inbound communications. Thus, in this example the asymmetric firewalls 18 and 19 have a much less restrictive security policy than the previously described firewall 13.
ICE begins normally with STUN communications 201 exchanged with STUN server 22 to determine the IP address X and UDP port number for IP address X for IP phone A. IP phone A then makes local STUN server 23 available on IP address X and associates unique identifier 8a with the local STUN server 23.
Next, IP phone A sends call request 202 to a VoIP call controller 1. Because it is an outbound communication, firewall 18 forwards the call request 202 to VoIP call controller 1. VoIP call controller 1 sends call request 203 to VoIP call controller 2, which sends call request 204 to IP phone B.
After receiving the call request 204, IP phone B sends the STUN request 205a to STUN server 22. IP phone B also sends a STUN request 206 to the STUN server 23. Firewall 19 has not previously forwarded outbound communications to IP phone B, and thus STUN request 206 is dropped.
As a result of receiving STUN response 205b back from STUN server 22, IP phone B makes local STUN server 24 available on the IP address Y and associates a unique identifier 8b with that IP address Y. Because firewall 19 intercepted and dropped the STUN request 206, ICE cannot be completed and multimedia communications cannot be transferred between IP phones A and B.
Because of the forgoing limitations, endpoints behind restrictive firewalls and restrictive NATs are unable to establish multimedia communications. Endpoints located behind asymmetric firewalls of varying security policies are also unable to establish multimedia communications. The disclosure that follows solves this and other problems.